-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement new registration flow with email verification #5215
base: main
Are you sure you want to change the base?
Conversation
Emergency access will fail
There is an Same with invitations /
|
23b0863
to
efc82da
Compare
Thanks for the testing @stefan0xC , I've fixed emergency access now and I'll look into the org invites tomorrow. |
@dani-garcia I'm not sure if accepting the emergency access invitation in vaultwarden/src/api/core/accounts.rs Line 329 in efc82da
|
Oops didn't notice the client was doing the accept right afterwards, same thing with the org invites so the only thing I do is validate the claims in the token match with the request now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dani-garcia I could not yet accept an organization invite. With the new registration flow a token
will not be send anymore so we should change it to org_invite_token
accordingly.
if Invitation::take(&email, &mut conn).await | ||
|| CONFIG.is_signup_allowed(&email) | ||
|| pending_emergency_access.is_some() | ||
|| pending_org_invite.is_some() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When inviting an User the entry in the table will already have been created, so this should not be necessary, I think.
With the new signup form will a data.token
ever get passed? If not
vaultwarden/src/api/core/accounts.rs
Lines 235 to 236 in 60a9474
if let Some(token) = data.token { | |
let claims = decode_invite(&token)?; |
data.org_invite_token
instead. (I mean, we'd probably want to keep it for backwards compatibility but accepting an invitation currently fails.)
email_verification_token: Option<String>, | ||
accept_emergency_access_id: Option<EmergencyAccessId>, | ||
accept_emergency_access_invite_token: Option<String>, | ||
org_invite_token: Option<String>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we get rid of token
and instead make it an alias for backwords compatibility?
org_invite_token: Option<String>, | |
#[serde(alias = "token")] | |
org_invite_token: Option<String>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I've tested it that seems to work both with web-v2025.1.1
(with and without the feature flags set) and web-v2025.1.2
.
New versions of the clients support a new registration flow that also allows enforcing email verification. This is a working implementation of that new API.
The clients implementations are gated behind two feature flags that I have enabled, I've used a web vault compiled from the main branch, but older releases might also work.
Still a draft as I still need to test Invites/emergency access